This invention relates generally to referencing objects in a programming environment and more specifically to managing objects.
Two common problems which occur in object oriented programming languages such as C++, are memory leaks and dangling pointers. A memory leak occurs when memory space is allocated for an object but never released after use. A dangling pointer points to a destroyed object or freed memory region. After an object is dynamically destroyed, any subsequent attempt to reference the destroyed object using the dangling pointer can have unpredictable and often disastrous results. For instance, if a reference to a destroyed object is used, the memory space can become corrupt and potentially cause the computer program, and perhaps the computer itself, to crash. These problems become even more pronounced in multi-threaded applications, particularly applications where an object has “suicide” methods (methods where an object will delete itself).
The C++ language allows objects to be constructed on the heap at runtime. These objects have to be deleted by the creating module or some other module when they are no longer required. However, this explicit object deletion can cause the two aforementioned common problems. First, if the object does not get deleted, this causes memory leaks making the program consume memory and starve other applications of memory. Second, if the objects are deleted too soon while some other module or thread still holds a pointer to the object, it will cause a crash when these pointers are used.
Existing solutions depend on the object to provide functionality to keep the reference count. This imposes restriction on the object makes the reference counting pointer not usable for any existing type of object. Referring to FIG. 1, there is shown a typical prior art solution The real object 102 contains the reference count 104 of the pointer object 106. The reference count 104 is kept and managed by the real object 102. Typically, the below code must be implemented by each real object to sue the smart pointer by way of inheritance from a common class or in the object itself.
class RealObject {  int m_refCount;public:  RealObject( ):m_refCount(0){}    AddRef( )      {        m_refCount++;      }    Release( )      {        m_refCount−−;        if(m_refCount == 0)          delete this;        }  }
If a member function has to return the ‘this’ pointer, then the implementation must call AddRef( ) before returning the ‘this’ pointer. For example:
PointerOjbect GetObjectPtr( ){  AddRef( );  // must be called to correct reference count.  return this;}
It should be noted that there is a ‘delete this’ in the Release( ) function. This is not legal in some compilers.
Many prior efforts result in the creation of pointer-objects that will allow the keeping a count of the object references held by modules and threads. These pointer-objects also delete the object when the last reference is released. However, there are two main drawbacks to these efforts. First, these pointer-objects impose implementation restrictions on the object and force the object itself to keep the reference count or inherit the count from a base object. This makes the pointer-object unusable to an existing real object. Also, case has to be taken to increment the reference count manually when handing out the object reference from within the object (‘this’ pointer). second, these pointers cannot be cast to other object pointers, thus losing the true nature of the pointer.
Thus the needs exists for a self-reference counting pointer that keeps the reference count of the object within the pointer object.